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Abstract 


This document specifies a Dynamic Host Configuration Protocol (DHCPv4 
and DHCPv6) option containing the civic location of the client or the 
DHCP server. The Location Configuration Information (LCI) includes 
information about the country, administrative units such as states, 
provinces, and cities, as well as street addresses, postal community 
names, and building information. The option allows multiple 
renditions of the same address in different scripts and languages. 
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Introduction 


Many end system services can benefit by knowing the approximate 
location of the end device. In particular, IP telephony devices need 
to know their location to contact the appropriate emergency response 
agency and to be found by emergency responders. 


There are two common ways to identify the location of an object, 
either through geospatial coordinates or by so-called civic 
addresses. Geospatial coordinates indicate longitude, latitude, and 
altitude, while civic addresses indicate a street address. 


The civic address is commonly, but not necessarily, closely related 
to the postal address, used by the local postal service to deliver 
mail. However, not all postal addresses correspond to street 
addresses. For example, the author’s address is a postal address 
that does not appear on any street or building sign. Naturally, post 
office boxes would be unsuitable for the purposes described here. 

The term /’civil address’ or ’jurisdictional address’ is also 
sometimes used instead of civic address. This document mainly 
supports civic addresses, but allows the postal community name to be 
indicated if it differs from the civic name. 


A related document [15] describes a DHCPv4 [2] option for conveying 
geospatial information to a device. This document describes how 
DHCPv4 and DHCPv6é [6] can be used to convey the civic and postal 
address to devices. Both geospatial and civic formats can be used 
simultaneously, increasing the chance to deliver accurate and timely 
location information to emergency responders. The reader should also 
be familiar with the concepts in [11], as many of the protocol 
elements below are designed to dovetail with PIDF-LO elements. 


This document only defines the delivery of location information from 
the DHCP server to the client, due to security concerns related to 
using DHCP to update the database. Within the GEOPRIV architecture 
as defined by RFC 3693 [9], the defined mechanism in this document 
for conveying initial location information is known as a "sighting" 
function. Sighting functions are not required to have security 
capabilities and are only intended to be configured in trusted and 
controlled environments. (A classic example of the sighting function 
is a Global Positioning System wired directly to a network node.) 
Further discussion of the protections that must be provided according 
to RFC 3694 [10] are in the Security Considerations (Section 6). 


End systems that obtain location information via the mechanism 
described here then use other protocol mechanisms to communicate this 
information to an emergency call center or to convey it as part of 
presence information. 
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Civic information is useful since it often provides additional, 
human-usable information, particularly within buildings. Also, 
compared to geospatial information, it is readily obtained for most 
occupied structures and can often be interpreted even if incomplete. 
For example, for many large university or corporate campuses, 
geocoding information to building and room granularity may not be 
readily available. 


Unlike geospatial information, the format for civic and postal 
information differs from country to country. The initial set of data 
fields is derived from standards published by the United States 
National Emergency Number Association (NENA) [18] and takes into 
account addressing conventions for a number of countries in different 
areas of the world. It is anticipated that other countries can reuse 
many of the data elements, but the document also establishes an IANA 
registry for defining additional civic location data fields. 


The same civic and postal address information can often be rendered 
in multiple languages and scripts. For example, Korean addresses are 
often shown in Hangul, Latin, and Kanji, while some older cities have 
multiple language variants (e.g., Munich, Muenchen, and Monaco). 
Since DHCPv4 and DHCPv6 do not currently support a mechanism to query 
for a specific script or language, the DHCP server SHOULD provide all 
common renderings to the client and MUST provide at least the 
rendering in the language and script appropriate to the location 
indicated. For example, for use in presence information, the target 
may be visiting from a foreign country and want to convey the 
information in a format suitable for watchers in its home country. 
For emergency services, the rendering in the local language is likely 
to be most appropriate. To provide multiple renderings, the server 
repeats sequences of address elements, prefixing each with a 
‘language’ and/or ‘script’ element (see Section 3.3). The language 
and script remain in effect for subsequent elements until overridden 
by another language or script element. Since the DHCP client is 
unlikely to be the final consumer of the location information, the 
DHCP server has to provide all appropriate language and script 
versions, which the client then passes on via some other GEOPRIV 
using protocol, typically encoded in a presence-based GEOPRIV 
location object format [16]. 


The DHCP server MAY provide location information for multiple 
locations related to the target, for example, both the network 
element and the network jack itself. This is likely to help in 
debugging network problems, for example. 


This document calls for various operational decisions. For example, 


an administrator has to decide when to provide the location of the 
DHCP server or other network elements even if these may be a good 


Schulzrinne Standards Track [Page 3] 


RFC 4676 DHCP Civic October 2006 


distance away from the client. The administrator must also consider 
whether to include both civic and geospatial information if these may 
differ. The document does not specify the criteria to be used in 
making these choices, as these choices are likely to depend strongly 
on local circumstances and need to be based on local, human 
knowledge. 


A system that works with location information configured by DHCP is 
dependent that the administrators of the DHCP systems are careful 
enough on a number of fronts, such as: 


- if information about one location is provided in multiple forms 
(e.g., in multiple languages), is it consistent? 


- is the administrator certain that location information is 
configured only to systems to which it applies (e.g., not to 
systems topologically near, but geographically far)? 


- if the location configured is not that of the target but that of a 
‘nearby’ network node or the DHCP server, despite the 
recommendation against this practice in Section 3.1, is the 
administrator certain that this configuration is geographically 
valid? 


There are many other considerations in ensuring that location 
information is handled safely and promptly for an emergency service 
in particular. Those are in the province of the applications which 
make use of the configured location information, and they are beyond 
the scope of this document. DHCP configuration SHOULD NOT be used 
for emergency services without guidelines on these considerations. 
Work on these is under way in the IETF ECRIT working group at the 
time of publication of this document. 


In addition, if a network provides civic location information via 
both DHCPv4 and DHCPv6, the information conveyed by two protocols 
MUST be the same. 


As discussed in the Security Considerations (Section 6), the 
GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when 
the DHCPv4 client has included this option in its /’/parameter request 
list’ (RFC 2131 [2], Section 3.5). Similarly, the 
OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only 
when the DHCPv6 client has included this option in its OPTION_ORO. 


The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be 


used if the civic address option exceeds the maximum DHCPv4 option 
size of 255 octets. 
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2g 


Bi. 


3x3 


Terminology 
In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 


and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 
indicate requirement levels for compliant implementations. 


Format of the DHCP Civic Location Option 


1. Overall Format for DHCPv4 


0 1 2 3 

Onl 2-3: 4°36 07 8-9-0: L234 br TB 9 Oa 203 425.6 78-9 01 
tot—t—t-4t-t-4t-4t-4+-4F-F-4-4-4-4-4-4-4-4-4- 4-4-4444 -totatatat-tat 
| GEOCONF_CIVIC | N | what | country | 
tot—t—t-t-t-4t-4t-4t-4F-4F-4-4-4-4-t-4-4 4-44-4444 -tototatatatatat 
| code | civic address elements sti 
+-+-+-+-+-+-+-+-+-+-+-+-+-H+tHH HHHH 


Code GEOCONF_CIVIC: The code for this DHCP option is 99. 


N: The length of this option is variable. The minimum length is 3 
octets. 

what: The ’what’ element describes to which location the DHCP entry 
refers. Currently, three options are defined: the location of the 


DHCP server (a value of 0), the location of the network element 
believed to be closest to the client (a value of 1), or the 
location of the client (a value of 2). Option (2) SHOULD be used, 
but may not be known. Options (0) and (1) SHOULD NOT be used 
unless it is known that the DHCP client is in close physical 
proximity to the server or network element. 


country code: The two-letter ISO 3166 country code in capital ASCII 
letters, e.g., DE or US. (Civic addresses always contain country 
designations, suggesting the use of a fixed-format field to save 
space.) 


civic address elements: Zero or more elements comprising the civic 
and/or postal address, with the format described below 
(Section 3.3). 
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3.2. Overall Format for DHCPv6 


The DHCPv6 [6] civic address option refers generally to the client as 
a whole. 


0 1 2 3 
012345678901234567890123456789041 
tat ata tatatatata tata tata ta tata tata ta tatatatatatatatatatatatatat 
OPTION_GEOCONF_CIVIC | option-len | 
—tatatatatatatata ta tata tata tata titatatatatatatatatatatata—t-t-tat 
what country code 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
civic address elements 


+— +— + 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
option-code: OPTION_GEOCONF_CIVIC (37) 


option-len: Length of the Countrycode, 'what’ and civic address 
elements in octets. 


what: See above (Section 3.1). 
country code: See above (Section 3.1). 
civic address elements: See above (Section 3.1). 


3.3. Element Format 


For both DHCPv4 and DHCPv6, each civic address element has the 
following format: 


+0 
O w 
m 


CAtype es 
—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


—+-+-+ 
CAtype: A one-octet descriptor of the data civic address value. 


CAlength: The length, in octets, of the CAvalue, not including the 
CAlength field itself. 


CAvalue: The civic address value, as described in detail below. 
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3.4. Civic Address Components 


Since each country has different administrative hierarchies, with 
often the same (English) names, this specification adopts a simple 
hierarchical notation that is then instantiated for each country. We 
assume that five levels are sufficient for sub-national divisions 
above the street level. 


All elements are OPTIONAL and can appear in any order. 


Component values MUST be encoded as UTF-8 [7]. They SHOULD be 
written in mixed case, following the customary spelling. The script 
indication (CAtype 128) MUST be written in mixed case, with the first 
letter a capital letter. 


Abbreviations MUST NOT be used unless indicated for each element. 
Abbreviations do not need a trailing period. 


It is RECOMMENDED that all elements in a particular script (CAtype 
128) and language (CAtype 0) be grouped together, as that reduces the 
number of script and language identifiers needed. 


For each script and language, elements SHOULD be included in numeric 
order from lowest to highest of their CAtype. In general, an element 
is labeled in its language and script by the most recent ’ language 
tag’ (CAtype ) element preceding it. Since not all elements depend 
on the script and language, a client accumulates the elements by 
CAtype and then selects the most desirable language and script 
rendition if there are multiple elements for the same CAtype. 


+-------- +------- +------------------------- 5 = + 

| CAtype | label | description 

+-------- +------- +-------------------- ---- - 5 5 5 = + 
1 Al national subdivisions (state, canton, region, 

province, prefecture) 

| | | | 

| 2 | A2 | county, parish, gun (JP), district (IN) 

| | | | 

| 3 | A3 | city, township, shi (JP) 

| 4 | A4 | city division, borough, city district, ward, | 

| | | chou (JP) | 

| | | | 

| 5 | a5 | neighborhood, block 

| | | | 

| 6 | A6 | group of streets below the neighborhood level | 

+------—- +------- +-------------------- = -- - = 5 5 + 


Table 1 
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For specific countries, the administrative sub-divisions are 
described below. 


CA (Canada): The mapping to NENA designations is shown in 
parentheses. Al designates the province (STA), A2 the county 
(CNA), A3 the city, town, or MSAG community name (MCN). 


DE (Germany): Al represents the state (Bundesstaat), A2 the county 
(Regierungsbezirk), A3 the city (Stadt, Gemeinde), A4 the district 
(Bezirk). Street suffixes (STS) are used only for designations 


that are a separate word (e.g., Marienthaler Strasse). 


JP (Japan): Al represents the metropolis (To, Fu) or prefecture 
(Ken, Do), A2 the city (Shi) or rural area (Gun), A3 the ward (Ku) 
or village (Mura), A4 the town (Chou or Machi), A5 the city 
district (Choume), and A6 the block (Banchi or Ban). 


KR (Korea): Al represents the province (Do), A2 the county (gun), A3 
the city or village (ri), A4 the urban district (gu), A5 the 
neighborhood (dong). 


US (United States): The mapping to NENA designations is shown in 
parentheses. Al designates the state (STA), using the two-letter 
state and possession abbreviations recommended by the United 
States Postal Service Publication 28 [17], Appendix B. A2 
designates the county, parish (Louisiana), or borough (Alaska) 
(CNA). A3 designates the civic community name, e.g., city or 
town. It is also known as the municipal jurisdiction or MSAG 
community name (MCN). The civic community name (A3) reflects the 
political boundaries. These boundaries may differ from postal 
delivery assignments, the postal community name (PCN), for 
historical or practical reasons. The optional element A4 contains 
the community place name, such as "New Hope Community" or 
"Urbanizacion" in Puerto Rico. 


Mappings and considerations from additional countries may be 
informally gathered from time to time in independent documents 
published by the IETF. These should be titled "Civic Address 
Considerations for [Country]" and should contain similar information 
to the examples given here. As published by the IETF, they will be 
non-normative and purely descriptive, like the examples here, and 
will not purport to speak with authority for any country, but rather 
be offered for information. If authors choose to label the document 
with a country code, this does not preclude its use for labeling a 
future coexisting document. 


Additional CA types appear in many countries and are simply omitted 
where they are not needed or known: 
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21 


22 


Schulzrinne 


LMK 


LOC 


NAM 


ZIP 


PCN 


LMK 


LOC 


NAM 


PC 


FLR 


SEAT 


DHCP Civic 


inser eon o e 
aaas Ma 
leading street direction 
trailing street suffix 
street suffix or type 

house number 

house number suffix 
landmark or vanity 
address 

additional location 
information 

name (residence and 
office occupant) 
postal/zip code 
building (structure) 
unit (apartment, suite) 
floor 

room 

type of place 

postal community name 
post office box (P.O. 
Box) 

additional code 

seat (desk, cubicle, 
workstation) 


primary road name 


Standards Track 


October 2006 


Examples 
i-default 
N 

SW 

Ave, Platz 
123 
A, 1/2 


Columbia 
University 


South Wing 
Joe’s 
Barbershop 
10027-1234 
Low Library 
Apt 42 

4 

450F 

office 
Leonia 


12345 


13203000003 


WS 181 


Broadway 


[3] 


et i at ae ae a et et + 
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petr Foeter tataan ta tars + 
| CAtype | NENA | PIDF | Description | Examples 
prh Feise prte ta tonsa + 
| 35 | | | road section | 14 

| | | | | | 
| 36 | | | branch road name | Lane 7 

| | | | | | 
| 37 | | | sub-branch road name | Alley 8 

| 38 | | | street name pre-modifier Old 

| | | | | | 
| 39 | | | street name post-modifier | Service 

| | | | | | 
| 128 | | | script | Latn | 
| | | | | | 
| 255 | | | reserved | | 
tee oso t------ foc bee SS SS E NET eS SS See Sass SS + 


The CA types labeled in the second column correspond to items from 
the NENA "Recommended Formats and Protocols For ALI Data Exchange, 
ALI Response and GIS Mapping" [18], but are applicable to most 
countries. The "NENA" column refers to the data dictionary name in 
Exhibit 18 of [18]. 


The column labeled PIDF indicates the element name from [16]. (Some 
elements were added to this document after the PIDF location object 
definition had been completed. These elements currently do not have 
a PIDF-LO equivalent.) 


Language: The "language" item (CAtype 0) optionally identifies the 
language used for presenting the address information, drawing from 
the tags for identifying languages in [4], as discussed in [13]. 
If omitted, the default value for this tag is "i-default" [3]. 


Script: The "script" item (CAtype 128) optionally identifies the 
script used for presenting the address information, drawing from 
the tags for identifying scripts described in [12] and elaborated 
on in Section 2.2.3 of [13]. If omitted, the default value for 
this tag is "Latn". 


POD, PRD: The abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be 
used for POD (trailing street suffix) and PRD (leading street 
direction) in English-speaking countries. 


STS: STS designates a street suffix or type. In the United States 


(US), the abbreviations recommended by the United States Postal 
Service Publication 28 [17], Appendix C, SHOULD be used. 
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HNS: HNS ("house number suffix") is a modifier to a street address; 
it does not identify parts of a street address. 


building: While a landmark (LMK, CAtype 21) can indicate a complex 
of buildings, ‘building’ (CAtype 25) conveys the name of a single 
building if the street address includes more than one building or 
if the building name is helpful in identifying the location. 


Loc: Loc ("location", CAtype 22) is an unstructured string 
specifying additional information about the location, such as the 
part of a building or other unstructured information. 


PCN: The postal community name (CAtype 30) and the post office box 
(CAtype 31) allow the recipient to construct a postal address. 
The post office box field should contain the words "P.O. Box" or 
other locally appropriate postal designation. 


NAM: The NAM object is used to aid user location ("Joe Miller", 
"Alice’s Dry Cleaning"). It does not identify the person using a 
communications device, but rather the person or organization 
associated with the address. 


LMK: While a landmark (LMK, CAtype 21) can indicate a complex of 
buildings, ‘’building’ (CAtype 25) conveys the name of a single 
building if the street address includes more than one building or 
the building name is helpful in identifying the location. (For 
example, on university campuses, the house number is often not 
displayed on buildings, whereas the building name is prominently 
shown.) 


Unit: The "unit" object (CAtype 26) contains the name or number of a 
part of a structure where there are separate administrative units, 
owners, or tenants, such as separate companies or families that 
occupy that structure. Common examples include suite or apartment 
designations. 


Room: A "room" (CAtype 28) is the smallest identifiable subdivision 
of a structure. 


Type of place: The "type of place" item (CAtype 29) describes the 
type of place described by the civic coordinates. For example, it 
describes whether it is a home, office, street, or other public 
space. The values are drawn from the items in the location types 
registry [11]. This information makes it easy, for example, for 
the DHCP client to then populate the presence information. Since 
this is an IANA-registered token, the language and script 
designations do not apply for this element. 
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Additional code: The "additional code" item (CAtype 32) provides an 
additional, country-specific code identifying the location. For 
example, for Japan, it contains the Japan Industry Standard (JIS) 


address code. The JIS address code provides a unique address 
inside of Japan, down to the level of indicating the floor of the 
building. 


SEAT: The "seat" item (CAtype 33) designates a place where a person 
might sit, such as a seat in a stadium or theater, or a cubicle in 
an open-plan office or a booth in a trade show. 


Primary road name: The "primary road" item (CAtype 34) is given to 
the road or street name associated with the address. If CAtypes 
35 through 37 are not specified, the building or designated 
location is found on that street. If some of CAtypes 35 through 
37 are specified, this designates the main road, off of which the 
smaller streets branch off and where the structure or building is 
actually located. 


Road section: The "road section" item (CAtype 35) designates a 
specific section or stretch of a primary road. This is a new 
thoroughfare element and is useful where a primary road is divided 
into sections that re-use the same street number ranges. 


Branch road name: The "branch road name" item (CAtype 36) represents 
the name or identifier of a road or street that intersects or is 
associated with a primary road. The branch road name is used only 
in countries where side streets do not have unique names within a 
municipality or other administrative unit, but rather must be 
qualified by the name of the primary road name that they branch 


off of. 

Sub-Branch road name: The "sub-branch road name" (CAtype 37) item 
represents the name of a street that branches off a branch road 
(CAtype 36). The sub-branch road name is used only in countries 


where such streets are named relative to the primary road name and 
branch road that they connect with. 


Street name pre-modifier: The "street name pre-modifier" (CAtype 38) 
is an optional element of the complete street name. It is a word 
or phrase that precedes all other elements of the street name and 
modifies it, but is separated from the street name by a street 
name pre-directional. An example is "Old" in "Old North First 
Street". 
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4. 


Street name post-modifier: The "street name post-modifier" (CAtype 
39) is an optional element of the complete street name. It is a 
word or phrase that follows all other elements of the street name 
and modifies it, but is separated from the street name by a street 
name post-directional and/or street suffix. An example is 
"Extended" in "East End Avenue Extended". 


Postal Addresses 


In general, a recipient can construct a postal address by using all 
language-appropriate elements, including the postal code (ZIP, CAtype 
24). However, certain elements override the civic address components 
to create a postal address. If the elements include a post office 
box (CAtype 31), the street address components (CAtype 34, PRD, POD, 
STS, HNO, HNS) are replaced with the post office box element. Ifa 
postal community name is specified, the civic community name 
(typically, A3) is replaced by the postal community name (PCN, CAtype 


30). Country-specific knowledge is required to create a valid postal 
address. The formating of such addresses is beyond the scope of this 
document. 
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5. Example 


Rather than showing the precise byte layout of a DHCP option, we show 
a symbolic example below, representing the civic address of the 
Munich city hall in Bavaria, Germany. The city and state name are 
also conveyed in English and Italian in addition to German; the other 
items are assumed to be common across all languages. All languages 
use the latin script. 


4+-------- 4+--------------------- + 
| CAtype | CAvalue | 
4+-------- 4+--------------------- + 
| 0 | de | 
hie ose | 
eg, seas | 
Pe an | 
| 3 | M=U+00FCnchen | 
Pane | 
lis fe | 
cae | 
| 24 | 80331 

| 29 | government-building | 
| 31 | Postfach 1000 | 
pe | 
s. [ES | 
Paice | 
ig Ma | 
i, aE | 
— ae | 
4+-------- 4--------------------- + 


Schulzrinne Standards Track [Page 14] 


RFC 4676 DHCP Civic October 2006 


6. 


Security Considerations 


The security considerations discussed in the GEOPRIV architecture 
defined by RFC 3693 [9] apply. 


Where critical decisions might be based on the value of this 
GEOCONF_CIVIC option, DHCPv4 authentication in RFC 3118 [5] SHOULD be 
used to protect the integrity of the DHCP options. 


Since there is no privacy protection for DHCP messages, an 
eavesdropper who can monitor the link between the DHCP server and 
requesting client can discover the information contained in this 
option. Thus, usage of this option on networks without access 
restrictions or network-layer or link-layer privacy mechanisms is NOT 
RECOMMENDED. 


To minimize the unintended exposure of location information, the 
GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when 
the DHCPv4 client has included this option in its /’/parameter request 
list’ (RFC 2131 [2], Section 3.5). Similarly, the 
OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only 
when the DHCPv6 client has included this option in its OPTION_ORO. 


After initial location information has been introduced, it MUST be 


afforded the protections defined in RFC 3694 [10]. Therefore, 
location information SHOULD NOT be sent from a DHCP client to a DHCP 
server. If a client decides to send location information to the 


server, it is implicitly granting that server unlimited retention and 
distribution permissions. 


IANA Considerations 


The IANA has registered new DHCPv4 and DHCPv6 option codes for the 
Civic Address (GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC, respectively). 


This document establishes a new IANA registry for CAtypes designating 
civic address components. Referring to RFC 2434 [14], this registry 
operates under both "Expert Review" and "Specification Required" 
rules. The IESG will appoint an Expert Reviewer who will advise IANA 
promptly on each request for a new or updated CAtype. 


CAtype: Numeric identifier, assigned by IANA. 


Brief description: Short description identifying the meaning of the 
element. 
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8. 


8. 


Reference to published specification: A stable reference to an RFC 
or other permanent and readily available reference, in sufficient 
detail so that interoperability between independent 
implementations is possible. 


Country-specific considerations: If applicable, notes whether the 
element is only applicable or defined for certain countries. 


The initial list of registrations is contained in Section 3.4. 


Updates to country-specific considerations for previously-defined 
CAtypes are not defined by IANA registrations since they are purely 
descriptive, not a registration of identifiers. As noted earlier, 
country-specific conventions may optionally be written up in 
documents titled "Civic Addresses for [Country]". 
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